Scheduling Within a Minor Frame

Scheduling Within a Minor Frame

Processes in a minor frame queue are dispatched in queue order. Initially, queue order is the order in which processes are named in frs_enqueue() calls. (The queues can be reordered dynamically; see "Managing Activity Processes".)

Scheduler Flags frs_run and frs_yield

The Frame Scheduler keeps two status flags per queued process, named frs_run and frs_yield. If a process is ready to run when its turn comes, it is dispatched and its frs_run flag is set to indicate that this process has run at least once within this minor frame.

When a process yields, its frs_yield flag is set to indicate that the process has released the processor. It will not be activated again within this minor frame.

If a process is not ready (usually because it is blocked waiting for I/O, a semaphore, or a lock), it is skipped. Upon reaching the end of the queue, the scheduler goes back to the beginning, in a round-robin fashion, searching for processes that have not yielded and may have become ready to run. If no ready processes are found, the Frame Scheduler goes into idle mode until a process becomes available or until an interrupt marks the end of the frame.

Detecting Overrun and Underrun

When a time base interrupt occurs to indicate the end of the minor frame, the Frame Scheduler checks the flags for each process. If the frs_run flag has not been set, that process never ran and therefore is a candidate for an underrun exception. If the frs_run flag is set but the frs_yield flag is not, the process is a candidate for an overrun exception.

Whether these exceptions are declared depends on the scheduling discipline assigned to the process. Scheduling disciplines are explained under "Using the Scheduling Disciplines").

At the end of a minor frame, the Frame Scheduler resets all frs_run flags, except for those of processes that use the Continuable discipline in that minor frame. For those processes, the residual frs_yield flags keeps the processes that have yielded from being dispatched in the next minor frame.

Underrun and overrun exceptions are typically communicated via IRIX signals. The rules for sending these signals are covered under "Using Signals Under the Frame Scheduler".

Estimating Available Time

It is up to you to make sure that all the processes equeued to any minor frame can actually complete their work in one minor-frame interval. If there is too much work for the available CPU cycles, overrun errors will occur.

Estimation is simplified by the fact that only the enqueued processes can execute in a CPU controlled by the Frame Scheduler. You need to estimate the maximum time each process can consume between one call to frs_yield() and the next.

Frame Scheduler processes do compete for CPU cycles with I/O interrupt service in the same CPU. If you direct I/O interrupts away from the CPU (see "Isolating a CPU From Sprayed Interrupts" and "Assigning Interrupts to CPUs"), then the only competition for CPU cycles (other than a very few essential TLB interrupts) is the overhead of the Frame Scheduler itself, and it has been carefully optimized for least overhead.

Alternatively, you may assign specific I/O interrupts to a CPU used by the Frame Scheduler. In that case, you must estimate the time that interrupt service will consume (see "Maximum Response Time Guarantee") and allow for it.